보다 나은 AWS Oragnizations 설계를 위한, OU(Organizational Units) 설계의 모범 사례
본 블로그의 내용은 아래의 AWS 공식 블로그의 원문을 한국어로 정리한 내용입니다.
Best Practices for Organizational Units with AWS Organizations
들어가기 앞서
안녕하세요, 클래스메소드의 서은우 입니다.
많은 분들이 사용자나 워크로드 등에 따라 여러 AWS 계정을 생성하는 다중 계정 전략(Multi Account strategy)을 사용하고 있을 것입니다.
하지만 서비스의 규모가 더욱 커지고 AWS 계정이 늘어나게 되면 각 계정의 관리나 비용 관리 등이 힘들어지게 되는데요.
이를 해결하기 위해 AWS Oragnizations를 사용하여, 계정들을 조직화하고 중앙 집중식으로 관리할 수 있는 다중 계정AWS 환경을 설정할 수 있습니다.
본 블로그에서는 AWS Orgaznizations 사용시 조직(OU, Organizational Units) 구축의 모범 사례에 대해 설명하고 있습니다.
AWS Orgaznizations 사용에 앞서 어떻게 OU를 구축하면 좋을지, 모범 사례를 통해 도움을 얻으실 수 있길 바랍니다.
제품 및 소프트웨어 개발 수명 주기(SDLC, Prod and Software Development Life Cycle)
서로 다른 정책을 가지고 있는 비프로덕션(SDLC) OU와 프로덕션(prod)에 대해, 개발, 테스트와 같은 비프로덕션(SDCL) OU는 다른 계정의 프로덕션(prod)에 대해 종속성이 없어야합니다.
비프로덕션과 프로덕션 환경에 대해, 각 환경의 요구 사항에 따라 개별 계정 수준이 아닌 OU 수준에서 정책을 적용하는 것이 바람직합니다.
기본 OU들 (Foundational OUs)
AWS는 보안과 인프라를 고려하여 기본 OU 집합을 만드는 것을 권장합니다. 때문에 보안과 인프라의 기반이 되는 OU를 기본 OU로써 구성하는 것이 좋습니다.
인프라 OU (Infrastructure OU)
네트워킹, IT 서비스와 같은 공유 인프라 서비스에 사용됩니다. 필요한 인프라 서비스에 따라 계정을 생성하는 것이 좋습니다.
예를 들어, 온프레미스 네트워크에 대한 액세스를 제공하는 3개의 공유 인프라 및 네트워킹 서비스, RabbitMQ를 사용하는 호스팅된 메시징 서비스 및 일반 공유 인프라 계정을 보유한 경우의 OU 및 계정 구조는 다음과 같습니다.
보안 OU (Security OU)
보안 관련 액세스 / 서비스를 호스팅하는 데 사용됩니다. 보안 OU와 그 하위 OU 및 연결된 계정은 보안을 취급하는 조직에서 소유하고 관리해야 합니다.
보안 OU의 구조의 예는 다음과 같습니다.
보안 OU의 추천 계정은 다음과 같습니다.
- Log Archive
- 자신 환경의 모든 AWS 계정에서 수집된 보안 지향적인 AWS 액세스 및 감사 로그에 대한 통합 지점 역할을 하는 AWS 계정
- Security ReadOnlyAccess (사람)
- 읽기 전용 권한으로 AWS 환경의 다른 AWS 계정에 액세스하여 감사, 보안 테스트 및 조사를 지원하는 목적의 계정
- Security Breakglass (사람):
- 보안 사고 발생시 보안 팀 구성원이 사용하기 위한 광범위한 쓰기 액세스가 가능한 계정(거의 사용되지 않음)
- Security Tooling (최소한의 사람)
- 광범위하게 적용 가능한 보안 지향 워크로드 및 서비스, 도구 및 지원 데이터를 호스팅하는 하나 이상의 AWS 계정
- GuardDuty 마스터 계정, Security Hub 마스터 계정 등
- 사람의 액세스를 최소화하는 것이 좋음
추가적으로 설정 가능한 OU (서비스 구축 또는 실행)
샌드박스 OU (Sandbox OU)
개별 기술자들이 AWS 서비스를 다룰 수 있게 하기 위한 AWS 계정입니다.
샌드박스 OU의 계정은 회사의 내부 네트워크에서 분리하고, 사용 가능한 비용의 상한을 정해두어 추적하는 것 등이 좋습니다.
워크로드 OU (Workloads OU)
소프트웨어 수명 주기와 관련된 AWS 계정이 생성되는 OU입니다. 배포된 애플리케이션에 대해 워크로드 계정을 생성하고 소프트웨어 서비스를 격리하는 것이 좋습니다.
SDLC/non-prod OU의 계정의 경우, 소프트웨어 서비스를 준비하기 위한 것이기 때문에 다른 OU에 종속되지 않아야 합니다.
다른 추가 OU의 계정은 워크로드/프로덕션 OU 계정에만 의존해야 합니다.
예를들어, 관리 및 운영 모델을 공유하는 제조, 고객 서비스 및 마케팅의 세 가지 비즈니스 유닛을 가지고 있으며, 고객 서비스에는 OU에는 없는 퍼블릭 베타 버전이 있는 경우의 구조는 다음과 같습니다.
AWS Organizations의 기본 OU 구성도
지금까지 살펴 본 내용들을 정리하면 다음과 같은 구성이 됩니다.
이러한 기본 구성만으로도 AWS 다중 계정을 관리할 수 있지만, 필요에 따라 다른 OU를 만드는 것도 좋습니다.
추가적으로 설정 가능한 OU (유지 관리 및 확장)
정책 검증용 OU (PolicyStaging OU)
조직에 정책 / 구조적 변경 등의 변경사항들을 확인하기 위한 OU 입니다. 정책 검증용 OU는 'non-prod OU'로, 하위 OU 및 계정을 생성하여 테스트를 진행하는 것이 좋습니다.
예를들어, 보안, 인프라, 워크로드, 코드 및 배포에 대한 정책들을 테스트하기 위해서는 다음과 같은 구조를 가질 수 있습니다.
정지 OU (Suspended OU)
폐기 예정인 AWS 계정을 포함하는 OU입니다. 모든 작업을 Deny 하는 SCP를 이 OU에 연결합니다.
이전 사원의 계정과 폐기 예정의 계정은 "정지(SUSPENDED)" 상태로 전환되어야 합니다.
90일 동안 폐쇄된 계정은 영구적으로 삭제될 수 있고, 이후에는 계정과 리소스를 복구할 수 없습니다.
폐쇄된 계정은 "정지(SUSPENDED)" 상태로 조직에서 확인할 수 있습니다. 영구적으로 삭제된 계정은 조직에 표시되지 않습니다.
개별 비즈니스 사용자 OU (IndividualBusinessUsers OU)
제한된 액세스를 허용하는 비즈니스 사용자의 AWS 계정을 위한 OU 입니다. 예를 들어 S3 버킷을 설정하여 보고서나 파일 등을 공유할 수 있습니다.
예외 OU (Exceptions OU)
비즈니스 Use case 에서 Workloads OU에 정의된 보안 / 감사 조건의 예외를 보장하는 경우, 예외를 부여하기 위한 OU 입니다.
이 경우, 계정에 직접 SCP를 적용하여 맞춤형 보안 스탠스를 취할 수 있습니다. 때문에 CloudWatch Events, Config Rules 와 같은 감지 및 대응 시스템에서 더욱 정밀한 조사를 기대할 수 있습니다.
과도기 OU (Transitional OU)
기존의 계정 및 워크로드를 통합하기 전에 조직으로 이동하는 대상 계정/워크로드를 임시로 보관하기 위한 영역입니다. 이 OU는 OU 구조에 맞지 않을 수도 있는 계정을 할당할 수 있는 임시 위치를 제공합니다.
배포 OU (Deployments OU)
CI/CD 배포를 위한 AWS 계정을 포함하는 OU 입니다.
워크로드 OU(Prod 및 SDLC)의 계정과 비교하여 CI/CD 배포에 대해 다른 거버넌스 및 운영 모델이 있는 경우, 이 OU를 생성하는 것이 좋습니다. 워크로드 OU의 애플리케이션에 대한 각 SDLC/Prod AWS 계정 세트에 대해 배포 OU에서 CI/CD용 계정을 생성합니다.
비프로덕션(non-production) OU의 계정은 CI/CD 서비스를 준비하기 위한 것이며 다른 OU의 종속성이 없어야 합니다.
총 정리
지금까지의 내용을 정리하면 아래와 같은 이미지로 OU를 설계할 수 있습니다. 기본이 되는 Security, Infrastructure OU를 구성한 후 필요한 기능에 따라 추가적으로 OU 를 구성해 나가는 것입니다.
끝으로
본 블로그(원문)는 OU 설계의 모범 사례에 대해 설명하고 있습니다. 모범 사례에 나온 OU 이외에도 필요한 기능이나, 요구 사항에 따라 다양한 OU가 필요하게 될 수도 있습니다.
